I can certainly understand the argument for reducing memory pressure when working with very large batch sizes and thus arrays, but I think the proposed solution of simply adding an array factory argument to Batch is very tricky to get right for the caller. In the simples of cases, it will lead to incorrect usage and bugs because it requires side effects (like lastSize in your example and test), additional work like clipping each bucket (because the actual array length may be greater than the requested bucket size, especially when renting from a pool) and finally returning each array to the pool at the right time for the reuse to be effective through the iterations. You can see that even in the example you posted in your opening comment, only the last bucket is returned to the pool whereas the rest leak. All this also make the composing with Batch very hard.

I think a sequence of buckets is probably the wrong return type for such an overload because it claims that each bucket is independent of another when that's not true, especially if the backing array is pooled. Each bucket will end up looking at the same array. This can cause even more severe logical bugs.

I've experimented with what a design could look for a version of Batch using pooled arrays and will share it through another PR. Unfortunately, it's not a simple set of changes or tweaks so it's best to share, discuss and review the code in a PR.